DiscordのInteractions APIとWebSocket (Gateway)
Gemini 2.5 Pro.icon
WebSocketが常にDiscordと接続して全ての出来事（イベント）をリアルタイムに受け取るための伝統的な仕組みであるのに対し、 そして、後にできたのはInteractions APIです。
2つのAPIの違い
用途
WS: メッセージの受信、リアクションの追加、ユーザーの参加/退出など、サーバー内で起こるあらゆるリアルタイムイベントの受信
Interactions API:スラッシュコマンド、ボタン、セレクトメニュー、右クリックメニューなど、ユーザーが起こした特定のアクションへの応答
接続方式
常時接続 (WebSocket)<br>Botは常にDiscordのサーバーに接続し続け、イベントが発生するとデータが送られてくる。
Interactions API: 都度リクエスト (HTTP Webhook)
ユーザーがコマンド等を使うと、DiscordがBotの指定したURLにHTTPリクエストを送ってくる。
イメージ
常に通話状態のトランシーバー 📡何かあればすぐ聞こえるが、常に電力を消費する。
Interactions API: 注文が入ると鳴るポケットベル 📟<普段は待機しており、呼ばれた時だけ応答する。
メリット
WS
全てのイベントをリアルタイムに取得できる
ユーザーのオンライン状態の監視など、幅広い機能が作れる
Interactions API
常時接続が不要で、サーバーの負荷が低い<br>・サーバーレス環境（AWS Lambdaなど）で運用しやすい<br>・大規模になっても管理がしやすい（スケーラブル）
デメリット
WS
常時接続を維持する必要があり、サーバーコストがかかる
Botが大規模になると接続の管理（シャーディング）が複雑になる
Interactions API
メッセージの受信など、インタラクション以外のイベントは受け取れない
答時間に制限がある（3秒以内に反応しないとエラーになる）
登場した経緯：なぜInteractions APIができたのか？
もともとDiscord Botは、WebSocket (Gateway) を使うのが唯一の方法でした。Botはサーバーに参加すると、そのサーバーで起こる全てのメッセージ投稿などのイベントをリアルタイムに受け取り、特定のメッセージ（例: !playなど）に反応して動くのが一般的でした。
しかし、この方式にはいくつかの課題がありました。
1. ユーザー体験の課題:
ユーザーはBotごとに異なるプレフィックス（!, ?, .など）を覚える必要がありました。
どんなコマンドが使えるか分からず、!helpと打って確認する必要がありました。
2. 開発者とDiscord側の課題:
Botはサーバー内の全てのメッセージを読み取る権限が必要な場合が多く、プライバシー上の懸念がありました。
Botが大規模になるほど、常時接続を維持するためのサーバーコストや技術的な複雑さが増大しました。
スラッシュコマンドをDiscordのUIに統合することで、ユーザーは/を打つだけで使えるコマンドの候補や説明を見ることができ、格段に使いやすくなりました。
裏側の仕組みとして、常時接続が不要でスケーラブルなInteractions APIが提供されたのです。
さらにDiscordは、プライバシー保護の観点から、2022年以降、特別な許可がない限りBotがサーバー内のメッセージ内容を読み取れないように仕様を変更しました。
これにより、多くのBotが旧来のプレフィックスコマンドから、Interactions APIを利用するスラッシュコマンドへと移行することになりました。
現在のBot開発では、両方のAPIを目的によって使い分けるのが一般的です。